In cellular networks, e.g., as specified by 3GPP (3rd Generation Partnership Project), congestions may occur on a radio interface which is used to convey data to and from a user equipment (UE). The risk of such congestions can be expected to increase with the ongoing growth of traffic volumes in cellular networks.
In 3GPP TS 23.401 V12.4.0 (2014-03), section 4.7.2, a bearer mechanism is described which may be used for ensuring a certain Quality of Service (QoS) treatment of Internet Protocol (IP) based user traffic. Traffic that requires differentiated QoS treatment is classified into bearers. For each bearer, a parameter referred to as QCI (QoS Class Identifier) determines the basic QoS treatment. Other parameters, such as the MBR (Maximum Bitrate), GBR (Guaranteed bitrate), UE or APN (Access Point Name) specific AMBR (Aggregate Maximum Bitrate), and ARP (Allocation and Retention Priority) parameters can further influence the quality of service applied to the traffic on a given bearer.
However, these QoS parameters do not support a predictable congestion management by the operator of the cellular network. For example, the GBR and MBR parameters only apply to GBR bearers while most of the traffic currently goes over non-GBR bearers. The AMBR parameter only allows to enforce a maximum over several bearers which is not flexible enough to specify congestion behavior.
Further, there can be many vendor-specific parameters which are based on the QCI and are set in the RAN. If RAN equipment from multiple vendors is used by the same operator, which is a common scenario, the overall result with respect to user experience may become unpredictable. Further, also such vendor-specific parameters may not be sufficient for managing the handling of congestions.
In 3GPP TR 23.705 V0.9.0 (2013-11), a number of solutions are suggested to address congestions. In some of these solutions congestion mitigation is implemented in a Radio Access Network (RAN) of the cellular network, while in other solutions congestion mitigation is implemented in a Core Network (CN) of the cellular network. In the following, the former class of solutions will be referred to as RAN-based solutions while the latter class of solutions will be referred to as CN-based solutions.
The CN-based solutions may suffer from a number of performance issues. These performance issues may for example result from the fact that a delayed feedback control is used, since the RAN reports congestions on a mid to long timescale, e.g., after several seconds or minutes. As a result, the CN only has delayed and limited information about the RAN congestion status. Furthermore, the delayed feedback may also result in oscillating system performance, which may in turn cause system instability. Further, as for example explained in 3GPP tdoc S2-134010 (SA WG2 Meeting #100, 11-15 Nov. 2013, San Francisco, USA), the CN-based solutions may be difficult to harmonize with existing RAN mechanisms.
Among the RAN-based solutions, some solutions are based on a packet marking indicated from the CN to the RAN.
For example, a solution referred to as “Solution 2.1: Flow priority-based traffic differentiation on the same QCI (FPI)” uses an FPI marking (FPI: Flow Priority Indicator) marking of data packets to determine the priority of a flow in the RAN. If the delay budget of a flow cannot be fulfilled, flows having the same QCI based priority are prioritized based on FPI priority. Besides the priority handling, there may also be an implementation specific starvation protection mechanism.
However, this solution may be problematic with respect to delay budget. For example, in the case of internet traffic typically a QCI of 9 or 8 is used, which means that delay budget is as high as 300 ms. Further, in typical implementations, Active Queue Management (AQM) techniques may be used in which data packets are actively dropped to avoid filling up the full buffer and keep the delay low. As a result, the delay may never reach the delay budget and FPI based prioritization becomes irrelevant. Further, if implementation specific conditions are used to avoid starvation, the solution may become difficult to manage by the operator.
Further, a solution referred to as “Solution 2.2: Flow and bearer QoS differentiation by RAN congestion handling description (FQI)” uses an FQI marking (FQI: Flow QoS Index) of data packets to refer to a specific RAN configuration which determines congestion handling. This RAN configuration is defined by a RAN Congestion Handling Descriptor (RCHD) which is defined per QCI, per FQI, and per congestion level.
In this solution the operator may for example define bitrate targets per congestion level and thereby influence the resource sharing in the RAN. While this may be used by the operator for congestion handling, it also introduces certain restrictions when it comes to how the congestion management is performed. One such restriction is that the congestion levels are defined in a specific manner. However, some operators may prefer one definition of the congestion levels, while other operators may prefer another definition of the congestion levels. Further, this solution defines a certain way of radio resource sharing which introduces a limitation to the RAN implementation.
Further, a solution referred to as “Solution 2.4: Differentiation of IP flows based on flow level QCI” uses packet marking to override the bearer QCI, and lets the flow QCI determine the RAN handling characteristics.
Further, a solution referred to as “Solution 2.3: Enhancing existing bearer concepts” is also a RAN-based solution, which however does not rely on packet marking. Rather, it relies on the current bearer based differentiation.
This solution may be problematic with respect to RAN implementation. For example, a RAN node would typically use different mechanisms to ensure QoS on a per bearer or per flow level. For example, the Packet Data Control Protocol (PDCP) and Radio Link Control (RLC) handling may be performed according to mechanisms on a per flow level, and this PDCP and RLC handling may be performed before scheduling on a per bearer level. For this reason, it may be hard to achieve the same QCI treatment on both the per bearer level and the per flow level. Further, problems may arise in terms of backwards compatibility with the existing QCI mechanism, because the bearer QCI is overridden.
Accordingly, there is a need for techniques which allow for efficiently managing the handling of congestions in a cellular network.